Garlic and onion hosting: how to raise a web resource without having your domain taken away

Disclaimer: the tools described here are absolutely legal. It's like a knife: some people cut cabbage into salad, others use it for attacks. Therefore, the post is dedicated exclusively to tools that can be used for both good and not so good purposes..

Global DNS is a wonderful thing that has survived many decades. But it has a fundamental problem - your domain can simply be divided if they suddenly decide that you have violated something. Well, or someone with money and connections will have a grudge against you. Everyone remembers the history of torrents.ru. If for some reason you want to eliminate such risks, you can look towards overlay networks, which simply do not have a regulator capable of separating a domain name. Therefore, we will raise onion and i2p web resources.

Onion rings

Let's start with the classics. I think that on Habré almost everyone used Tor in the form of a bundle Tor-browser. This helped me a lot when, in the process of hunting for Telegram, they suddenly began to abruptly break off connections with the largest hosters in the most unexpected places. In this mode, Tor uses classic onion encryption, wrapping data in layers in such a way that it is impossible to determine the source and final destination of the packet. Nevertheless, the final point of the route is still the regular Internet, where we eventually get through Exit nodes.

This solution has several problems:

1. Unfriendly people may come to the owner of an Exit node and begin to claim that the owner is an inveterate criminal who swears bad words at government officials. There is a non-zero risk that few people will listen to your explanations about the fact that you are only an output node.
2. Using the tor network as a proxy to regular resources anonymizes the client, but does not help in any way against domain division and claims against the owner of the service.

Preparing content and a regular web server

Therefore, we will raise the onion resource directly within the network, without access to the regular Internet. For example, as an additional backup entry point to your resource. Let's assume that you already have a web server with some content that nginx serves. To begin with, if you do not want to be visible on the public Internet, do not be lazy to go to iptables and configure the firewall. You should be blocked from accessing your web server from anywhere except localhost. As a result, you received a site accessible locally at localhost:8080/. Additional screwing https here will be redundant, since the tor transport will take on this task.

Deploying TOR

I will consider the installation using Ubuntu as an example, but there will be no fundamental differences with other distributions. First, let's decide on the repository. Official documentation does not recommend using packages that are maintained by the distribution itself, as they may contain critical vulnerabilities that have already been fixed by upstream developers. Moreover, the developers recommend using the unattended-upgrades automatic update mechanism to ensure their timely delivery.

Create a file for an additional repository:

# nano /etc/apt/sources.list.d/tor.list

And add the necessary addresses to it:

deb https://deb.torproject.org/torproject.org bionic main
deb-src https://deb.torproject.org/torproject.org bionic main

Now we need to take care of the gpg key, without which the server will quite reasonably not trust new packages.

# curl https://deb.torproject.org/torproject.org A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --import
# gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -

Now you can install the main package from upstream and the keychain for automatic signature renewal.

# apt update
# apt install tor deb.torproject.org-keyring

Setting up proxying

In /etc/tor/torrc you will find the daemon configuration file. After updating it, do not forget to restart it.
I would like to immediately warn particularly curious users. Do not enable relay mode on your home machine! Especially in exit node mode. They might knock. On a VPS, I would also not configure the node as a relay, as this will create quite a significant load on both the processor and traffic. On a wide channel you can easily get 2-3 terabytes per month.

Find the following section in torrc:

############### This section is just for location-hidden services ###

Here you need to register your localhost web resource. Like that:

HiddenServiceDir /Library/Tor/var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:8080

Or you can use unix sockets:

HiddenServiceDir /Library/Tor/var/lib/tor/hidden_service/
HiddenServicePort 80 unix:/path/to/socket

Getting the address

That’s it, now let’s restart the tor daemon via systemctl and look in HiddenServiceDir. There will be several files there - a private key and your “onion” hostname. It is a 16 character random identifier. For example, gjobqjj7wyczbqie.onion — Candle search resource address. The address is completely random, but with a long enough search, you can generate a human-readable pair from the address and the private key. Of course, not all 16 characters - that would take billions of years. For example, the well-known catalog of books Flibusta has a mirror flibustahezeous3.onion, and Facebook spent a lot of resources to choose the most harmonious from the generated options: facebookcorewwwi.onion.

That's it, after some time your resource will be announced and become globally available. Please note that you can proxy not only the http protocol, but also any other.

Garlic

The second option was intended to be even more paranoid in nature. The i2p project was not initially conceived as a means for proxying traffic to the regular Internet and, by architecture, is a completely closed overlay network. There are separate gates in both directions, but this is rather an exception. Moreover, it is potentially unsafe.


Red logo of the reference i2p and purple i2pd implementation

i2p has several options for implementing software router nodes. The official implementation is written in Java. And it simply monstrously devours all available resources, both in terms of RAM and CPU. Nevertheless, it is the one that is considered the reference and undergoes regular audits. I would recommend that you use a much more lightweight option - i2pd, written in C++. It has its own nuances, due to which some i2p applications may not work, but overall it is an excellent alternative implementation. The project is currently under active development.

Installing the daemon

The most convenient thing is that the authors have provided many deployment options, including docker and snap. You can go the classic repository route.

sudo add-apt-repository ppa:purplei2p/i2pd
sudo apt-get update
sudo apt-get install i2pd

But I would recommend using snap. It will not only quickly and conveniently deploy the daemon, but will also provide automatic updates directly from the upstream, depending on the selected distribution channel.

no_face@i2pd:~$ snap info i2pd
name:      i2pd
summary:   Distributed anonymous networking framework
publisher: Darknet Villain (supervillain)
store-url: https://snapcraft.io/i2pd
license:   BSD-3-Clause
description: |
  i2pd (I2P Daemon) is a full-featured C++ implementation of I2P client.
  I2P (Invisible Internet Protocol) is a universal anonymous network layer.
  All communications over I2P are anonymous and end-to-end encrypted,
  participants don't reveal their real IP addresses.
snap-id: clap1qoxuw4OdjJHVqEeHEqBBgIvwOTv
channels:
  latest/stable:    2.32.1 2020-06-02 (62) 16MB -
  latest/candidate: ↑
  latest/beta:      ↑
  latest/edge:      2.32.1 2020-06-02 (62) 16MB -

Install snap if you haven't already and set stable as default:

apt install snapd
snap install i2pd

Configuring

i2pd, unlike the web-gui Java version, does not have so many settings, twists and tabs. Only the most necessary things to the point of asceticism. However, the easiest way would be to configure it directly in the configuration file.

In order for your web resource to become available in i2p, it must be proxyed in the same way as with onion. To do this, go to the file ~/.i2pd/tunnels.conf and add your backend.

[anon-website]
type = http
host = 127.0.0.1
port = 8080
keys = anon-website.dat

After restarting the daemon, you will receive a random 32-bit address. It can be viewed in the web console, which is available by default in 127.0.0.1:7070/?page=i2p_tunnels. Don't forget to allow access from your IP address if necessary. By default, it is only available on the local interface. There will be something scary like ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p.

There is a semblance of DNS in an i2p network, but it is more like a scattered list of /etc/hosts. You subscribe in the console to specific sources that tell you how to get to the conditional flibusta.i2p. Therefore, it makes sense to add a more or less beautiful name to large resources like inr.i2p.

Is it possible to deploy i2p and onion here??

I would like to warn you right away that RuVDS is not a bulletproof hosting service. In the event of a motivated complaint against our client, we can terminate the contract and extinguish the virtual machine. Most hosters will do the same. However, due to the peculiarities of the architecture of tor and especially i2p, it is very difficult, and often simply impossible, to determine where exactly the website is hosted.

However, there is nothing illegal in the very use of such tools. Therefore, we will not object if you open a mirror of your legal web resource in overlay networks. In any case, I once again strongly recommend not to blindly experiment with tor on your home machine. Either the IP may get blacklisted, or the party will come. Better rent a VPS, it's inexpensive.